Re: to implement the iphone-like 'floating scrollbar'

["Pengcheng Zou" <pengchengzou gmail com>]

On Jan 25, 2008 6:38 AM, Freddie Unpenstein <fredderic excite com> wrote:
> Presumably, you'd make it visible when the underlying range widget complains about being changed, and then 
> hide it again after some timeout.

that's what i am doing. the tricky part is how to draw the scrollbar
right on top of the underneath viewport and the widgets contained in
the viewport.

> What I'm trying to figure out, though, is how do you scroll a widget, if its scrollbar only appears after 
> the content has been scrolled?!?  (And assuming you don't have a scroll wheel on your mouse.)

i used some controls make by openmoko, the basic idea is to cover a
eventbox onto the viewport, and the eventbox would steal the mouse
event and handle the scrolling.

> Or are you planning to implement automatic click-and-drag scrolling for the associated content somehow.  
> And if you are, what happens if the content has interactive widgets, or drag sources, or whatever else.

at least it works for labels and gtkentry, since press/release events
will be passed to the widget. drag&drop will be in conflict but
hopefully i can disable dnd later.

> And are you planning to have the scrollbar just float, or steal some size from the widget as automatic 
> scrollbars do at present?  And then if it floats, will the other scrollbar appear also so you can get to 
> the content now hidden?  Or does the user just have to sit there and wait until it hides itself again?  And 
> who gets to decide how long that is?!?

ideally the scrollbar should just float above the scrolled window.
when it appears, user can just wait until it hides, the timeout will
be pre-determined.

> Interesting idea...  Though I can't imagine it being more useful, than hindering, for most computer users.

it could be useful at least for mobile user. since the screen space is
too small to hold the scrollbars all the time.

> What WOULD be useful, though, is two individual features;
>
>
>
> 1) A "click-and-drag scrolling" derivative of GtkScrolledWindow.  I'd make it a derrived widget, since I 
> can't imagine how allowing contained widgets to remain interactive could be useful, and an entirely 
> separate widget states that much better, plus keeps the two opposing logics clearly separate.

openmoko guys did a great job on this, check this out:
http://svnweb.openmoko.org/trunk/applications/fingerscroll/?rev=2486#dirlist

> 2) A handle box type widget that hides its content until the mouse comes near.  This could be set to either 
> float or inline.  In float, you'd display a grip-bar to let the user know that there's something there, and 
> then pop-up the contained widget over top (covering but not actually replacing the grip bar) when the mouse 
> comes near it.  In inline, you'd replace the grip bar with the contained widget while the mouse was in the 
> vicinity, and swap them back when the mouse moved away.

it would be better if both the scrollbar and the stuff in the
scrollwindow can be display'd simultaneously, still does not figure
out how to do it correctly. to float the scrollbar on the widget, the
scrollbar can only be paint after all other widgets are repainted. i
tried to postpone the scrollbar repaint event, it seems works.

> Inline mode here, should be easy (except, possibly, for the "in the vicinity" part, if you wanted to allow 
> a few pixels leeway).  The underlying widget would take care of the need to present the opposing scrollbar 
> where needed.  In the float case, I suppose if you centered the contained widget (there should be an 
> alignment setting for this, though) over the grab bar, it would work on that basis of "just deal with it".  
> ;)
>
>
>
> The grip bar in either case would have a minimum size (that of a normal grip bar, square), and would 
> usually be extended to fit either horizontally or vertically, by the widget it's embedded within (HBox, 
> VBox, or ScrolledWindow, etc.).  The contained widget would, of course, would be expandable similarly.
>
>
>
>
>
> I've got a helper function presently, somewhere, that adds click-and-drag scrolling functionality to 
> widgets.  It'd be interesting to see it absorbed into a real widget.  Although I'd find the popup on 
> mouse-near behaviour most annoying personally.
>
>
>
>
>
> Fredderic
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!